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1 PURPOSE AND SCOPE 

1.1 Purpose 

ADSL service providers are highly interested in advancing DSL to be the preferred broadband access 
technology by growing their networks, increasing the value provided by those networks, and expanding the 
market they can address. To do this they must address several critical needs, particularly: 

• The service must become more accessible to end-users and to wholesale and retail partners. 

• The service must address a wider market with: 

o Variable speeds, 

o Variable precedence arrangements - allowing some application's traffic to take precedence 
over others. - 

o Specific support for IP applications (e.g. IP-QoS and multicasting); 

o Support for new business models that can include more types of service providers, and 

o Support for these new service parameters across multiple connections to different service 
providers from a single DSL subscriber. 

• The service must be competitive with alternative access technologies such as cable modem. 

While new architectures, like FSVDSL, may also fulfill these need s [Text has been edited in WT-080v4. section 
1.1, to: "While VDSL may also fulfil! these needs. . . ."1 . perhaps even better than ADSL, it is also important to 
realize that much ADSL has already been deployed, and that the current business imperatives may cause 
ADSL service providers to try to make more of what they already have than to try massive upgrades along with 
the massive capital investment they usually bring. 

Therefore, there is also a critical need to provide a standard evolution path for the embedded base of ADSL. 

The purpose of this work and the new service models is to provide a more common architecture and set of 
service interfaces to address these critical needs. Adhering to this architecture and to the services and service 
models set forth both here and in WT80 simplifies and unifies the way for all types of service providers to obtain 
ADSL end-user customers whether they sell access to networks, applications, or content. 

The anticipated outcome for employing this specification, as well as others that build from it, is that it will: 

• Reduce the number of alternative interfaces to ISPs/ASP and end users, in order to reduce costs 
through common interconnection. 

• Establish guidelines for developers and vendors, so they can build equipment that support common 
service requirements. 

• Improve the ability to introduce end-to-end services and applications worldwide, so that similar services 
can interwork across various service providers' networks. 

1.2 Scope 

This document presents an architecture for evolving DSL deployment and interconnection. It outlines a common 
methodology for delivering QoS-enabled applications to DSL subscribers from one or more Service Providers. 
The. business framework and drivers justifying this architectural evolution are described, in part, in WT-080. In 
the largest sense, the scope of this architecture is to provide IP-QoS and more flexible service arrangements to 
millions of users and thousands of service providers to a useful extent with highly economic enhancements to 
existing ADSL networks. 

While ADSL is useful for mass markets, segments and niches - this architecture addresses the mass market 
specifically. The approach, service models, and architecture are intended to scale to thousands of service 
providers, and many millions of end-users. The architecture does not detail approaches and techniques that 
might be appropriate to segments and niches, but does recognize that they might also be used in concert with 
this approach. 
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Many of the requirements levied on network elements and management systems are collected in this 
architecture, but they should not be taken as an exhaustive list of requirements for such elements. It is expected 
that other documents and standards will come forward to collect the requirements here, as well as those from 
other markets, segments, and niches in order to provide complete requirements for elements and systems that 
wish to be suitable in the DSL industry. 

This architecture provides a high-level, evolving view of ADSL access. Because of this it provides more details 
about things that will happen sooner and fewer details about things that are several years and phases from 
fruition. Also, unlike a design, this architecture does not provide exhaustive instructions on how to develop and 
deploy networks or elements that adhere to the architecture. In fact, it identifies the need to develop and 
standardize new functions, features, and protocols in many later-phase areas. 

1.3 Requirements 

In this document, several words are used to signify the requirements of the specification. These words are often 
capitalized. 

MUST This word, or the adjective "REQUIRED", means that the definition is an absolute requirement 

of the specification 

MUST NOT This phrase means that the definition is an absolute prohibition of the specification. 

SHOULD This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in 
particular circumstances to ignore this item, but the full implications must be understood and 
carefully weighted before choosing a different course. 

MAY This word, or the adjective "OPTIONAL", means that this item is one of an allowed set of 

alternatives. An implementation that does not include this option MUST be prepared to inter- 
operate with another implementation that does include the option. 

2 PRODUCTS AND SERVICES 

2.1 Service Goals 

Despite efforts to unify the architecture of Service Provider connections and to provide common 
service tiers, there has not been general support for a unified architecture. This proposal intends to 
increase the interest in such an architecture by increasing the number of service parameters 
available as well as by making those parameters more dynamic. Aside from variable dynamic 
bandwidth, this new architecture includes Quality of Service (QoS) and multi-application/multi- 
destination selection. 

Service Providers benefit in that they will only need to develop one set of system interfaces for any 
carrier that adopts this architecture. By subscribing to these interfaces, Service Providers will now be 
able to develop applications that can take advantage of variable bandwidth and better than "best 
effort" data traffic delivery. Subscribers will be able to realize greater potential of their broadband data 
connections. This means that a subscriber can still use their Internet access as it exists today; yet 
additional bandwidth on their DSL line can be used to deliver other applications, such as direct 
corporate access, video chat and video conferencing, and various content on demand, be it movies, 
games, software, or time-shifted television programs. Finally, these applications can be given QoS 
treatment, so that business access, online gaming, and casual internet access all share bandwidth 
appropriately. Both subscribers and Service Providers will be able to decide among connections, who 
provides the best service for a specific application, and what applications add the .most value. 

2.2 Product and Service Lists 

This document presents a proposal for evolving DSL deployment and interconnection. It will outline a 
common methodology for delivering QoS-enabled applications to DSL subscribers from multiple 
Service Providers. These products and services are intended to address the mass market, and do 
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not preclude additional niche or custom services that could be provided using the same 

?™^n any ° f T 6nt ProdUCtS ° ffered today either be ada P ted to or already 

Ms to™* S £ need6d *° SUPP ° rt ** pr ° p0Sed architectures contained within 

sz^^is^ requirements to support * e prap ° sed ™ ~*» mo de i, 

♦ IP-based services and QoS 

♦ COntr °' P ' ane f ' n WT -° 80v4 - " Disti ^ f Qitwork and application control 
interfacing with a common data re pository"] H — 52 

♦ The migration of DSL to leverage newer, alternative transport technologies 

rjjjt^'E^ " mind ' 3 tBn,fcn P ' an that identffies an interim > hase before --hing 

22£f Valen lS S o?^ SefViCe m0del ' where subs cn'ber connections are delivered in a best effort 
S i^nro Ver AJl i PV ?i w,l L continue to e ^st- Howevetfthis service model cannot support many of 

^^eS.^^ indUdin9 ,P °* b ~ " ^ 

♦ Subscriber access using PPP oE aggregated into L2TP tunnels delivered to Network Service Providers 
pSSST aCC6SS USinQ PPP ° E ° r ' P ° V6r Bhemet a 99 re 9 ated int0 VPNs deliv *ed to Network Service 

♦ nSt^ SS fT? ^ PF ! 0E ° r ,P 0ver Ethemet a 99regated into a common, public, QoS-enabled IP 
network and delivered to Application Service Providers. eu ,r 

Srvic^Ivv^^^V 6 ^^^ P , Ut forward by this document enables the fol,owin 9 Products and 
services fvVT-080 ter minology = -service feature^ which are described in WT-080. 

♦ Bandwidth on Demand 

♦ QoS, including QoS on Demand 

♦ Many-tc-Many Access 

♦ Content Distribution 

Network Service Providers will be able to benefit from the aggregation capabilities of the new DSL Access 
SSSS^SSi T S d0C T. nt S , PeCifiCa " y ' thiS arch ^ Cture wiil also Permit : IDelSnf of^ 
arrrerent. would it be a o ood idea to ahpn both texts?] 5 

♦ Traffic Aggregation: The end-to-end ATM PVC models, whether VPC or VCC, do not provide a 

scalable solution. L2TP and IP are used to provide better scalability and 
efficiency. 

♦ Improved Transport: Currentjy.most DSL transport is done over ATM connections. By offering 

other transport options, like Packet over SONET (POS) and Metro Ethernet 
this architecture can provide better scalability, reduced overhead and 
increased flexibility over ATM. 

♦ Simpler Provisioning: Because they are not directly linked to provisioning transport, L2TP and IP 

delivery models can reduce the level of per subscriber provisioning. 
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♦ Differentiated Services: Up until now, almost all DSL transport has been best effort delivery at a fixed 

rate. This new IP based architecture will permit Service Providers to offer 
differentiated treatment for certain traffic. 

♦ Increased Access: In previous architectures, Service Providers could only reach those 

subscribers with whom they had a direct relationship. These new 
architectures permit a subscriber to connect simultaneously to multiple 
Service Providers for a variety of services. Service Providers no longer need 
to be the sole provider to their subscribers. 

♦ Standard Connections: Up until now, each access provider has had their own set of interfaces for 

Service Providers. This proposal defines common interfaces for NSPs and 
ASPs. This means that the Service Provider need only develop a single 
interface to get all of these features for many access providers. Also, 
subscriber connections will be similar among Access Providers, allowing 
common CPE to be more widely deployed . 

Support for these new services will require a new set of network management interfaces. These interfaces will 
be used by both Service Providers and Subscribers. Service Providers will be able to examine the network and 
see how their subscribers are provisioned. NSPs will also be provided an interface to control and troubleshoot 
subscriber connections. 

Subscribers will be provided mechanisms for requesting these new services and signaling specific needs. 
These requirements will support applications and services like: 

♦ Multicast audio and video media applications 

♦ Video on demand applications 

♦ Voice services 

♦ Interactive gaming 

♦ Variable bandwidth, both on demand ('Turbo" button) and by application 

3 FUNCTIONAL ASSUMPTIONS 

3.1 Key Terminology 

The following definitions apply for the purposes of this document: 

Access Network The Access Network encompasses the elements of the DSL 

network from the NID at the customer premises to the BRAS. This 
network typically includes one or more types of Access Node and 
often an ATM switching function to aggregate them. 

Access Node The Access Node contains the ATU-C, which terminates the DSL 

signal, and physically can be a DSLAM, Next Generation DLC (NG- 
DLC), or a Remote Access Multiplexer (RAM). A DSLAM hub can be 
used in a central office to aggregate traffic from multiple remote 
physical devices, and is considered logically to be a part of the 
Access Node. When the term "DSLAM" is used in this document, it 
is intended'to very specifically refer to a DSLAM, and not the more 
generic Access Node. The Access Node provides aggregation 
capabilities between the Access Network and the Regional Network. 
It is the first point in the network where traffic on multiple DSL lines 
will be aggregated onto a single network. 

Broadband Remote Access Server (BRAS) The BRAS is the aggregation point for the subscriber traffic. 

It provides aggregation capabilities (e.g. IP, PPP, ATM) between the 



4 



DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services WT-081 



Regional/Access Network and the NSP or ASP. Beyond 
aggregation, it is also the injection point for policy management and 
IP QoS in the Regional/Access Networks. 

The center core of the Regional Network. The functions contained 
herein are primarily transport oriented with associated switching or 
routing capabilities enabling the proper distribution of the data traffic. 

The direction of transmission from the ATU-C (Access Node) to the 
ATU-R (modem). 

The edge of the Regional Network. The Edge Network provides 
access to various layer 2 services and connects to the Regional 
Network core enabling the distribution of the data traffic between 
various edge devices. 

Layer 2 Tunnel Switch (L2TS) The L2TS provides a second layer of PPP aggregation beyond the 

L2TP Access Concentrator (LAC). PPP sessions are switched 
between L2TP tunnels and are further aggregated and delivered to 
the NSP. 

Loop A metallic pair of wires running from the customer's premises to the 

Access Node. 

Many-to-Many Access Sessions The ability for multiple individual users or subscribers, within a single 

premises, to simultaneously connect to multiple NSPs and ASPs. 

PVC Bundle Two or more ATM PVCs (called a "bundle") are co-terminated on 

router endpoints. Each bundle co-termination is bound to a single IP 
interface. That is, the two (or more) PVCs appear to be a single "link 
layer" to the IP layer and so share a single set of routes. DiffServ, 
TOS marking, or other IP QoS mechanisms are used to select which 
of the two or more PVCs to use in either direction. Currently PVC 
bundles apply only to routed, not bridged interfaces. 

The Regional Network interconnects between the Network Service 
Provider's network and the Access Network. A Regional Network for 
DSL connects to the BRAS, which is technically both in the Regional 
Network and in an Access Network. Typically more than once 
Access Network is connected to a common Regional Network. The 
function of the Regional Network in this document goes beyond 
traditional transport, and may include aggregation, routing, and 
switching. 

The Regional and Access Networks - grouped as and end-to-end 
QoS domain and often managed by a single provider. - 

A customer premises functional element that provides IP routing and 
QoS capabilities. It may be integrated into or be separate from the 
ATU-R. 

Subscriber The client that is purchasing the DSL circuit from the Service 

Provider and is receiving the billing. 

Upstream The direction of transmission from the ATU-R (modem) to the ATU- 

C (Access Node). 

User Typically, a member., employee or guest at the Subscriber's 

household or business using the DSL circuit capabilities. 



Core Network 

Downstream 
Edge Network 



Regional Network 

Regional/Access Network 
Routing Gateway 
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3.2 Broadband Provider Reference Definitions 

TNote that some extra paragraphs were added in vVT-080. section 5. Mav-be these paragra phs could be added 
here as well?] 

Generally, services over a DSL access-based broadband network will be provided and supported by a number 
of different operational organizations. These organizations may be part of one company or more than one 
company. Leaving commercial issues aside, it is necessary to have a clear idea of the roles of the different 
organizations and how the functionality of equipment, network management, and test equipment can support 
their ability to discharge their roles for the benefit of the end customers. In order to provide a baseline with which 
to contrast, this document provides a common architectural view of DSL architecture in Figure 1 . 
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Figure 1 - DSL Network Components 
(Voice components not shown for clarity) 

Boxes in the figures represent functional entities - networks and logical components rather than physical 
elements. 

This traditional architecture is centered on providing service to a line or a loop. It is desired, however, to be able 
to provide services that are user-specific. Additionally, more than one subscriber can be present at the same 
premises and share a single loop. There is a need, therefore, to describe a slightly more complex situation, and 
hiding the common complexity shared with Figure 1 , this description is provided in Figure 2 below. Note that the 
figure shows many-to-many access through a common Regional/Access network. It is used to simultaneously 
provide an Application Service, between an ASP Network, and User, at the same time and over the same U 
interface as it supports a Network Service2 between NSP Network 2 and User 2 . 
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Figure 2 - Many-to-Many Access 

m^rJm^n^ th L k8y com P° nents of a Ds >- access-based broadband network. They indicate ownership of 
the components to different providing organizations. The role of these various providers is indSfeS S 

fNote that in WT-080 NSP anri ASP have bran PHiteH | 
The Network Service Provider (NSP): 

Includes Internet Service Providers (ISPs) and Corporate Service Providers (CSPs) 
is responsible for overall service assurance 

May provide CPE, or software to run on customer^wned CPE, to support a given service 
th* se^ 6 ° USt0mer COnbCt P ° int f ° r and a " CUSt ° mer related problems related t0 the P^ision of 
Authenticates access and provides and manages the IP address to the subscribers 

The Application Service Provider (ASP): 

Provides application services to the subscriber (gaming, video, content on demand, IP Telephony etc ) 
b respons.ble for the service assurance relating to this application service ' 
rSJSS f0r h Pr0V / ding 10 subscri bers addrtional software or CPE which specific services may require 
a^^ 

Does not provide or manage the IP address to the subscribers 
The Loop Provider 

Provides a metallic loop from the Access Network equipment to the customer's premises 
Is responsible for the integrity of the metallic loop ac-d its repair 

™2Lh S . PrOV ? d f Access Network Provider aggregated access to remotely deployed DSL equipment 
owned, operated, and maintained by the Loop Provider equipment 

The Access Network Provider 

♦ Provides digital connectivity to the customer via the metallic Loop 

♦ Is responsible for the performance and repair of the access transmission equipment 



♦ 
♦ 
♦ 
♦ 



♦ 
♦ 
♦ 
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The Regional Network Provider: 

♦ Provides appropriate connectivity between the Access Network and the NSPs and ASPs 

♦ Is responsible for Regional Network performance and repair , 

3.3 Interfaces 

These interfaces are key to this architecture, and have been modified or expanded from historical architectures 
(except the U interface) and represent requirements specific to the service models detailed herein and in WT- 
080. 

3.3.1 A10-ASP Interface 

This reference point is between the Regional/Access Network and the ASP's Points of Presence (POPs). This 
interface will consist of a routed IP interface, that may be transported over Fast Ethernet, Gigabit Ethernet 
Packet over SONET (POS), or some other IP interface. The ASP has the end-to-end Service responsibility to 
the customer for their specific application and is viewed as the "Retailer" of the specific service. Trouble reports 
for the specific service go directly to the ASP. 

3.3.2 A10-NSP Interface 

This reference point is between the Regional/Access Network and the NSP's POPs. The interfaces could be 
ATM Fast Ethernet, Gigabit Ethernet, or Packet over SONET (POS). In the case of ATM, multiple sessions 
may be multiplexed over a single VCC at this interface. Typically, the NSP has the end-to-end I service 
responsibility to the customer and is viewed as the "Retailer" of the service. As the retailer of the DSL service, 
trouble reports, and other issues from the subscriber are typically addressed to the NSP. Handoff protocols 
■ could include ATM VPA/Cs, L2TP tunnels, and routed protocols using IP-VPNs. 

3.3.3 U Interface 

The U Interface is located at the subscriber premise between the Access Node and the Network DSL 
Termination Device. 

3.3.4 T Interface 

The T Interface defines the interworking between the DSL modem/Routing Gateway and other CPE in the 
Customer Premises Network (CPN). The requirements for new vertical services over DSL require the addition 
of a Routing Gateway as the intermediate point between the DSL modem and the LAN Devices. The primary 
goal of this interface is to facilitate seamless transmission of IP packets in both a best effort approach as well as 
maintaining predefined QoS behavior or establishing dynamic QoS behaviors through a signaling mechanism. 
The DSL modem and Routing Gateway may or may not be a single device. 

4 REFERENCE ARCHITECTURE 

4.1 Logical Reference Architecture 

As noted in Section 3.2 above, the end-to-end DSL network consists of four providers. Of these providers, the 
two that this proposal most affects are the Regional Network Provider and the Access Network Provider. 
Historically the Regional Network has been a network of ATM switches, as shown in Figure 3. This is because 
the access to most Access Nodes is an ATM based interface. Some Access Networks even have their own 
ATM switches used to aggregate traffic from multiple Access Nodes. 
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Figure 3 - ATM based Regional and Access Network Providers 

in this architecture, there are no mechanisms for limiting subscriber traffic except for per line profiles within the 
Access Nodes. As many DSL networks were deployed before the advent of the BRAS, almost all the Access 
Network Providers use fixed speed profiles in the Access Nodes to limit upstream and downstream traffic. Even 
if the Service Provider were to attempt to send more traffic into the Regional Network than the Access Node is 
set to permit, the Access Node will police the downstream traffic. Since most Internet-based applications use 
TCP as the transport protocol, the traffic rejected at the Access Node will trigger TCP back-off, effectively 
throttling the downstream bandwidth. As such, most Service Providers also shape downstream traffic at the 
subscriber-selected bandwidth. However, the desire to move to a rate adaptive bandwidth model means that 
both the Regional and Access Networks could be vulnerable to traffic overloading. A means to control upstream 
and downstream traffic is needed as this architecture evolves. 

Many times the physical components of the Access Nodes are daisy-chained, sharing the bandwidth of the 
aggregating circuit. As shown in Figure 13 in Section 4.2.5.4, there are numerous ways that DSL access 
devices can be interconnected to the first ATM switch. While historical measurements have shown that the 
typical DSL subscriber uses no more than a small fraction of sustained bandwidth, the fact is that as subscribers 
are offered more and more high bandwidth applications, the average sustained bandwidth per subscriber over 
these "mid-mile" connections is going to increase. As per subscriber bandwidth usage increases, the Regional 
Network Provider will also need to scale bandwidth and provide subscriber-level granularity. ATM VPs do not 
provide the granularity necessary to offer per application QoS on a per subscriber basis. 
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Figure 4 - BP Enabled Regional Network 
As a result, other devices need to be added to the Regional Network to provide better aggregator i of subscriber 
traffic There are several options for doing this, most of which involve IP enabling the Reg.onal Network as 
shown in Figure 4. Subscribers that use native IP, which is a routable protocol, can be aggregated at the IP level 
into a Virtual LAN (VLAN) or Virtual Private Network (VPN) for handoff to their associated Service Provider 
Those subscribers that use variations of the Point-to-Point Protocol (PPP), such as PPPoA (PPP over ATM) 
and PPPoE (PPP over Ethernet), can be aggregated at either the PPP or the IP layer. 
If the aggregation is done at the PPP layer, then these PPP sessions will need to be forwarded over a routable 
protocol such as Layer 2 Tunneling Protocol (L2TP). When the new subscriber aggregation elemen is 
functioning in this mode, it is referred to as an L2TP Access Concentrator or LAC. The other option for PPP 
based subscriber is to also terminate the PPP session and assign IP addresses to the subscribers. Th.s traffic 
would then be collected into a VLAN or VPN as with native IP traffic. When performing PPP Termination and 
Aggregation (PTA), the box is typically called a Broadband Remote Access Server or BRAS. 
As more and more DSL aggregation is performed at the IP layer rather thanthe ATM layer, additional transport 
options may be added. In addftion to ATM, Ethernet and Packet over SONET are atao options for W 
There are various metropolitan Ethernet solutions available in speeds of 10 Mbps (Ethernet), 100 Mbps (Fast 
Ethernet), or 1 Gbps (Gigabit Ethernet or GigE). Metropolitan Ethernet connections have the added benefits of 
being less costly than Frame Relay, ATM, or private line circuits. 

These new network elements also need to be able to function as the first tier ATM aggregation device where 
the Access Node is now directly connected. As such, these devices will also need to handle ATM evel 
aggregation and switching and need to function as an adjunct to the existing ATM network Since they are IP 
aware they can also serve as the Label Edge Router (LER) that is required if the Core Network is to become 
Multi Protocol Label Switching (MPLS) aware. This would be shown in Figure 4 by collapsing the BRAS and 
ATM switch into a single multi-protocol device. 



4.2 Logical Elements and Interfaces 
4.2.1 Application Service Provider Network 
4.2.1.1 Description 

The Application Service Provider (ASP) is defined as a Service Provider that shares a common infrastructure 
provided by the Regional/Access Network and an IP address assigned and managed by the Regional Network 
Provider This is a new application of DSL service. The Regional Network Provider owns and procures 
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addresses that they, in turn, allocate to the subscribers. ASPs then use this common infrastructure in order to 
provide application or network services to those subscribers. For example, an ASP may offer gaming, Video on 
Demand, or even filtered Internet access, or access to VPNs via IPsec or some other IP-tunneling method. The 
ASP service may be subscriber-specific, or communal when an address is shared using Network Address Port 
Translation (NAPT) throughout a Customer Premises Network (CPN). It is envisioned that the ASP environment 
will have user-level rather than network-access-ievel identification, and that a common Lightweight Directory 
Access Protocol (LDAP) directory will assist in providing user identification and preference s fin WT-080v4: "a 
common repository will assist in providing user identification and preferences fTR-0461"] . Logical elements used 
by ASPs typically include routers, application servers, and directory servers. The relationship between the ASP 
Network, the A10-ASP interface, and the Regional Network is shown in Figure 2. 

4.2.1.2 Capabilities 

The capabilities of the ASP include but are not limited to the following: 

♦ Authenticating users at the CPN 

♦ Assignment of user profile or preference data 

♦ Assignment of QoS to service traffic 

♦ Customer service and troubleshooting of network access and application-specific problems 

♦ Ability to determine traffic usage for accounting purposes and billing 

rWT-080v4 has extra requirements in section 5.1 .2. Are these extra requirements also relevant for WT- 
081 ?1 



4.2.2 A10-ASP Interface 
4.2.2.1 Functionality 

As shown in Figure 5, the A10-ASP interface defines the interworking between the ASP Network and the 
Regional/Access Network. This is not a traditional interface. However, in order to provide more technical and 
business options to would-be broadband content and application providers this document defines a way for a 
Service Provider to attach a server, servers, or entire network to a common infrastructure directly accessible by 
DSL subscribers. Providing the A10-ASP interface is intended to promote content on demand, IP telephony, 
gaming, and other Quality of Service (QoS) or Bandwidth on Demand (BoD) applications without the need to 
deploy or manage an IP infrastructure. This also conserves IP addresses, as a single address can be used to 
gain access to all the services and providers that opt to share this infrastructure. 





Application 




BRAS 



J 





A10-ASP 
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4.2.2.2 



Figure 5 - A10-ASP Interface 
Communication Protocols 



This interface MUST,,, support IP networking connectivity to the DSL subscribers. Several QoS and BoD use 
cases exist: 



Best effort IP networking is used with no additional QoS or information required. 
Differentiated Services (Diffserv) QoS is provided in order to establish a higher class of service - oriented 
toward higher throughput, packet precedence, or lower latency. 

One or more Resource-Request Protocol (RRP) Is i gnaling protocol ], that is yet to be defined is used to 
receive BoD grants independent of precedence or assured resources, dynamic admittance to a traffic 
precedence class, assured bandwidth, or some combination of these.. RRP could be or could include 
RSVP and SIP p-ham is a difference between the ASP-u s e-rase-3 and the corresponding NSP-use-case- 
3 (section 4.2.4.31 The latter has a MAY and MUSH 
The communications protocol stack is shown in the following Figure 6. 

A10-ASP 



Resource - Request 
Protocol (RRP) 



Diffserv-enabled IP 



ATM, Ethernet, 
Frame Relay, POS 



Various PHY 



Figure 6 - ASP Protocol Stack with QoS 
The ASP obtains an IP connection over a typical data link layer as described earlier. More likely is that an ASP 
actually obtains a 10 Base-T, 100 Base-T, or GigE connection to the Regional/Access Network wrth.n a co- 
location or hosting facility. The Regional/Access Network provider statically assigns the addresses, and MAY H 
provide address blocks to the ASP. 
Network Layer 

The network layer interface MUST ra support IP version 4 in accordance with IETF RFC 1042. 
The network layer MAY H) support IP version 6 in accordance with IETF RFC 2460. 
The network layer interface SHOULD [5) support IP multicast. 

The network layer interface MUST® support IP precedence based on Diffserv Code Point (DSCP) markings, in 
accordance with IETF RFC 3140 when that type of QoS is offered. Q find it difficult to understand the real 
meaning of this MUST. Because of the "when that tvoe of QoS is offered" it sounds like a MAY.. .1 



The network layer interface MAY [7] support IP precedence based on a RRP signaled grant. 
Data Link Layer 
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The data link layer SHOULD^ support Ethernet in hosiing or co-location sites. 
The data link layer MAY m support ATM, Frame Relay, and/or POS. 
Physical Layer 

The physical layer interface MUST [10] support the following: 

♦ Ethernet PHY for 10 Mbps, 100 Mbps, 1 Gbps 

♦ DS1.DS3 

♦ 003,0012,0048 



4-2.3 Network Service Provider Network 
4.2.3.1 Description 

The Network Service Provider (NSP) is defined as a Service Provider that provides some service that requires 
extending a Service Provider-specific Internet Protocol (IP) address. This is the typical application of DSL 
service today. The NSP owns and procures addresses that they, in turn, allocate individually or in blocks to their 
subscribers. The subscribers are typically located in Customer Premises Networks (CPNs). The NSP service 
may be subscriber-specific, or communal when an address is shared using NAPT throughout a CPN. This 
relationship among the NSP, A10-NSP interface, and Regional/Access Network is shown in Figure 2. NSPs 
typically provide access to the Internet, but may provide access to a walled garden, VPN, or some other closed 
group or controlled access services. L2TP and IP VPNs are typical A10-NSP interface arrangements. 

The capabilities of the NSP include but are not limited to the following: 

• Authenticating network access between the CPN and the NSP network 

• Assignment of network addresses and IP filters 

• Assignment of traffic engineering parameters 

• Customer service and troubleshooting of network access problems 

4.2.4 A10-NSP interface 

4.2.4.1 Functionality 

As shown in Figure 7 and Figure 9, the A10-NSP interface defines the interworking between the NSP and the 
Regional/Access Network provider. This document offers the following Layer 2 and Layer 3 options for this 
interconnection. 

4.2.4.2 Communication Protocols: L2TP Connection 

This interface MUST m] support the Layer 2 PPP connection service supported by L2TP. Using Figure 8 as a 
reference, subscribers MUST [12 ) be placed into L2TP tunnels in one of the following methods: 

1 . L2TP tunnels MAY [13) be established or provisioned statically between LNS and the LAC or through an 
intervening Layer 2 Tunnel Switch (L2TS). 

2. L2TP tunnels MAY [14j be established dynamically using RADIUS in order to determine which users to add 
to various L2TP tunnels, including potentially new ones. As before, these may be directly between LAC and 
LNS or via L2TS. 
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A10-NSP 



Figure 7 - A10-NSP Interface Supporting L2TP Connection 
One or more sessions can be established to NSPs and are chosen by the fully qualified domain name (FQDN) 
of the accessing subscriber. 

Business models that require limiting subscriber access to a single NSP SHOULD^ be supported through 
administrative limits on the FQDN routing established by the Regional/Access Network provider on behalf of 
one or more NSPs. Subscribers SHOULD [16] be able to establish multiple L2TP access sessions to the same or 
to different NSPs. 

The RADIUS response MAY |17) be used to determine the bandwidth profile for its access session. 
The communications protocol stack is shown in the Figure 8. 



A10-NSP 



L2TP 



RADIUS 



Diffserv-enabled IP 



ATM, Ethernet, 
Frame Relay, POS 



Various PHY 



Figure 8 - L2TP Protocol Stack 

While L2TP over IP is always JteeJ used, as opposed to L2TP delivered directly over ATM or Frame Relay 
various IP transport options can be provided by the Regional/Access Network provider or selected by the NSP 
according to availability, regulation, and economics. 



14 



DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services 



WT-081 



Network Layer 

The network layer interface MUST nfl support IP version 4 in accordance with IETF RFC 1042. 
The network layer MAY m support IP version 6 in accordance with IETF RFC 2460. 
The network layer MUSTpg make use of L2TP over IP in accordance with IETF RFC 2661 . 
Data Link Layer 

The data link layer SH0ULD P1] support ATM. 

The data link layer MAYpg support Ethernet, Frame Relay, and/or POS. 

Physical Layer 

The physical layer interface MUSTpg support the following: 

♦ Ethernet PHY for 10 Mbps, 100 Mbps, 1 Gbps 

♦ DS1,DS3 

♦ OC3.OC12.OC48 

4.2.4.3 Communication Protocols: IP Routed Connection > 

This interface MUST p4] support the Layer 3 IP routed connection. Using Figure 9 as a reference, subscribers 
MUSTpsj be placed into IP routed networks in one of the following methods: 

1 . IP address pools MAY m be established or provisioned statically. 

2. IP addresses MAY^ be provided in pools that are distributed dynamically by the Regional/Access Network 
provider. 

3. IP addresses MAY m be established dynamically using RADIUS. 

4. IP addresses MAY [29] be assigned from named pools in cases where the NSP opts to allocate addresses 
out of two or more pools based on subscriber-specific information. 




A10-NSP 

Figure 9 - A10-NSP Interface Supporting IP Routed Connection 

in every case, RADIUS MUST^ be used between the BRAS (or a potential RADIUS proxy) and an NSP- 
designated AAA system or systems to authenticate subscriber access to the routed network. 
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In most cases, the IP routed network will be comprised of many IP-VPNs that support sharing of the 
Regional/Access Network at the IP layer. 

Because multiple services are potentially provided across the U interface, access to the IP network will be 
governed, as with L2TP, using the FQDN of the accessing subscriber. Subscribers MUST P1] be able to 
. establish multiple access sessions to the same or to different NSPs. Business models that require restricting the 
network access MUSTpzj be supported through administrative limits on the FQDN routing established by the 
Regional/Access Network provider on behalf of one or more NSPs. 

If. an NSP connects to the Regional/Access Network in several places; the A10-NSP interface SHOULD^ 
support BGP4 as per IETF RFC 1 745. 

Several QoS and BoD use cases exist: 

1 . Best effort IP networking is used with no additional QoS or information required. 

2. Diffserv QoS MAYp4 3 be supported and MUSTpg be used in order to establish a higher class of service - 
oriented either toward higher throughput, or lower latency. 

3. RRP signaling MAY m be supported and MUST p7 ] be used to receive BoD grants independent of 
precedence or assured resources, dynamic admittance to a traffic precedence class, assured bandwidth, 
or some combination of these.. 

The communications protocol stack is shown in Figure 10. 

A10-NSP 



RRP 



RADIUS 



Diffserv-enabled IP 



ATM, Ethernet, 
Frame Relay, POS 



Various PHY 



Figure 10 - Routed IP Protocol Stack with QoS 

IP MUSTps) always be used; however, various IP transport options can be provided by the Regional/Access 
Network provider or selected by the NSP according to availability, regulation and economics. As described 
earlier, RADIUS MUST p9] always used to authenticate users, SHOULD [40 ] be used to set NSP-desired filters, 
and MAY^ be used to assign addresses. 

Network Layer 

The network layer interface MUST^ support IP version 4 in accordance with IETF RFC 1042. 
The network layer interface SHOULD (43 ] support IP multicast. 

The network layer interface MUST [44] support IP precedence based on Diffserv Code Point (DSCP) markings, in 
accordance with IETF RFC 3140 when this type of QoS is offered. 

The network layer MAY [453 support IP version 6 in accordance with IETF RFC 2460. 

The network layer interface MAY [46] support IP QoS types based on RRP in order to receive BoD grants 
independent of precedence or assured resources, dynamic admittance to a traffic precedence class, assured 
bandwidth, or some combination of these . [The text here is different from th e similar ASP text in 4.2.2.2 "The 
network layer interface MAY support IP precedence based on a RRP si gnaled arantM 
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Data Link Layer 

The data link layer SHOULD^ support ATM 

The data link layer MAY^ support Ethernet, Frame Relay, and/or POS. . 
Physical Layer 

The physical layer interface MUST^ support the following: 

♦ Ethernet PHY for 10 Mbps, 100 Mbps, 1 Gbps 

♦ DS1.DS3 

♦ 003,0012,0048 

4.2.5 Regional/Access Network 

The Regional/Access Network consists of the Regional Network, Broadband Remote Access Server, and the 
Access Network as shown in Figure 1 1 . Its primary function is to provide end-to-end transport between the 
customer premises and the NSP or ASP. The Regional/Access Network may also provide higher layer functions 
such as QoS and content distribution. QoS will be provided by tightly coupling traffic-engineering capabilities of 
the Regional Network with the capabilities of the BRAS. Depending on the type and frequency of use, certain 
content storage may be pushed further out in the Regional/Access Network than others. As a result, 
functionality to support content distribution could be located at different points within the Regional/Access 
Network, but will not be located between the BRAS and the subscriber. 




Figure 11 - Components of the Regional/ Access Network 



4.2.5.1 Regional Network 

The Regional Network connects one or more BRAS and associated Access Network to NSPs and ASPs. It 
supports aggregation of traffic from multiple Access Networks and hands off larger geographic locations to 
NSPs and ASPs - relieving a potential requirement for them to build infrastructure to attach more directly to the 
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various Access Network. This arrangement is shown in Figure 12, that pictures a NSP and an ASP attached to 
a Regional Network in order to gain access to 3 Access networks. This architecture assumes that the network 
providers of the Regional and Access Networks work extremely closely in order to provide an end-to-end QoS 
solution. A good assumption might be that the 2 neworks are operated and managed by a single service 
providing entity and offered as a combined, Regional/Access Network. 




Access Network 



Customer Prem. Net 



Regional Broadband 
Network 



Access Network 



Access Network 




Customer Prem. Net 



Figure 12 - Aggregation function of Regional Network 

The Regional Network may transport traffic using ATM, Ethernet, or IP MPLS. Within these networking 
technologies, the Regional Network MUST m provide scalable traffic engineering capabilities to preserve IP 
QoS. 

4.2.5.2 Broadband Remote Access Server 

The BRAS performs multiple functions in the network. Its most basic function is to provide aggregation 
capabilities between the Regional/Access Network and the NSP/ASP. For the aggregation internet traffic, the 
BRAS serves as a L2TP Access Concentrator (LAC) tunneling multiple subscriber PPP sessions direcfly to an 
NSP or switched through a L2TS. It also performs aggregation for terminated PPP sessions or routed IP 
session by placing them into IP VPNs or 802.1Q VLANs. The BRAS also supports ATM termination and 
aggregation functions. 

Beyond aggregation, the BRAS is also the injection point for providing policy management and IP QoS in the 
Regional and Access Networks. The BRAS is fundamental to supporting the concept of many-to-many access 
sessions. 

Policy information can be applied to terminated, and non-terminated sessions. For example, a bandwidth policy 
may be applied to a subscriber whose PPP session is aggregated into an L2TP tunnel and is not terminated by 
the BRAS. However, sessions that terminate on (or are routed through) the BRAS can receive per flow 
treatment because the BRAS has IP level awareness of the session. In this model, not only can the aggregate 
bandwidth for a customer be controlled but also the bandwidth and treatment of traffic on a per application 
basis. 

The delivery of content has shifted from content that was more download intensive with lower bandwidth and 
best effort quality to one that is more real-time in nature, requiring higher bandwidth with higher quality. Some of 
the higher bandwidth applications include Video on Demand (VoD) for movies, Multicast (Broadcast -TV), and 
MPEG Unicast video Given the BRAS's proximity to the edge of the network and its ability to support IP 
services, the BRAS MUST [51) also provide support for content distribution and efficient use of multicast services. 

Some high level functional requirements are for the BRAS are listed below. This list is not comprehensive and 
additional requirements for QoS are listed in Section 5. 
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♦ The BRAS MUST^ be able to aggregate PPP sessions in the L2TP tunnels. 

♦ The BRAS MUST^ be able to switch PPP sessions between- L2TP tunnels. 

♦ The BRAS MUST M be able to terminate PPPoE sessions and assign routing attributes based on 
subscriber profile. 

♦ The BRAS MUST^ support authentication using RADIUS. 

♦ The BRAS MUSTpej support IP over bridged Ethernet (IETF RFC 2684). 

♦ The. BRAS MUST^ support address allocation using Dynamic Host Configuration Protocol (DHCP). 

♦ The BRAS MUST f58) support multiple Vcs per subscriber. 

♦ The BRAS SHOULD^ support ATM VC/VP pass-through switching functions. 

♦ The BRAS MUST^ support termination and aggregation of ATM VCs. 

♦ The BRAS SHOULD^ support the following ATM classes of service: UBR, UBR+, CBR, VBR-nrt, VBR-rt . 

♦ The BRAS MUST^ allocate downstream bandwidth based on policy configuration across ATM, PPP, 
Ethernet, and IP technologies. 

♦ The BRAS MUST^ mark IP QoS fields for upstream and downstream traffic based on policy configuration. 

♦ The BRAS MUST^ police IP QoS markings arid bandwidth allocation based on policy configuration. 

♦ The BRAS MUST [6 5j support queuing and prioritization based on IP QoS marks. 

♦ The BRAS MUST^ support traffic engineering for networking technologies including ATM, MPLS, and 
Ethernet. 

♦ The BRAS MUST [67] support a Diffserv-aware hierarchical scheduler that allows It to manage the network 
so that any potential congestion in the Access Network between the BRAS and the RGs is avoided The 
hierarchical scheduler in the BRAS MUST^ be able to model the congestion points in at least two subsequent ATM 
hops (corresponding to the daisy chaining of two ATM switching/multiplexing points in the Access Node); if the 
BRAS does not include the ATM swifching function, then the hierarchical scheduler in the BRAS MUST [69] be 
able to model the congestion point in yet an additional ATM hop. 

♦ When operating in an IP-routed mode, the BRAS MUSTpro] provide multicast support by implementing: 

♦ Host Extensions for IP Multicasting defined in IETF RFC 1112 

♦ Internet Group Management Protocol, Version 2 (IGMP v2) defined in IETF RFC 2236 

♦ Protocol Independent Multicast-Sparse Mode as defined in IETF RFC 2362. 
. ♦ MBGP as per IETF RFC 2858 

♦ The BRAS SHOULD^ support LAN interfaces for the local attachment of content distribution servers. 

♦ When operating in an IP-routed mode the BRAS MAY^ provide multicast access control and collect 
multicast usage information. 



4.2.5.3 Access Network 
Description 

fin this paragraph, the access network extends till the ATU-C/Access Node, while in other parts of WT-081 the 
access network has been extended to include the pari between the Access Node and BRAS] 

The Access Network refers to the network between the ATU-R and the ATU-C/Access Node. The protocols 
between these devices are well defined and this recommendation does not attempt to alter them. 



4.2.5.4 Access Node 
Description 

The Access Node contains the ATU-C, which terminates the DSL signal. Physically, the ATU-C can be 
deployed in the central office in a DSLAM, or remotely in a remote DSLAM (RT-DSLAM), Next Generation 
Digital Loop Carrier (NG-DLC), or a Remote Access Multiplexer (RAM). A DSLAM hub can be used in a central 
office to aggregate traffic from multiple remote physical devices, and is considered logically to be a part of the 
Access Node. 
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The Access Node provides aggregation capabilities between the Access Network and the Regional Network. It 
is the first point in the network where traffic on multiple DSL lines will be aggregated onto a single netoork. 
Traditionally the Access Node has been primarily an ATM concentrator, mapping PVCs from the ATU-R to 
PVCs in the ATM core. The role of the Access Node will change slightly in order to open up the DSL line for IP 
QoS services. The current responsibility of policing ATU-R to ATU-C PVCs to the subscribed line rate will be 
moved from the Access Node to the BRAS functional element. The Access Node will set line rate for each PVC 
at the synch rate (or slightly less) of the ATU-R and ATU-C. This will make the maximum amount of subscnber 
bandwidth available for services while retaining the ability to police individual sessions/flows as required. 
Various physical Access Node configurations are shown in Figure 13, with brief names for the configurations 
listed in Table 1. . ; 

In order to allow IP QoS support over an existing non-IP-aware layer 2 network without using multiple layer 2 
QoS classes, a mechanism based on hierarchical scheduling is used. This mechanism which is further 
described in section 5, preserves IP QoS over the ATM network between the BRAS and the RGs by carefully 
controlling downstream traffic in the BRAS, so that significant queuing and congeston does not occur further 
down the ATM network. This is achieved by using a hierarchy of scheduling steps in the BRAS that will account 
for downstream trunk bandwidths and DSL synch rates. As the depth of non-IP aware nodes between the 
BRAS and RG increases, the complexity of implementing hierarchical scheduling grows as well. In order to 
minimize this complexity, the daisy chaining MUST NOTp, exceed a depth of more than two A™ sw.toh.ng / 
multiplexing points including the Access Node and subtending Access Nodes. Additionally, if the BRAS £oes 
not incorporate the ATM switching functionality, an additional layer of hierarchical scheduling MUST^j be used 
to manage the trunk to the ATM switch. 
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Figure 13 - Access Node Architecture Variations 



Table 1 - Access Node Architecture Variation Descriptions 



Reference # 


Description 


1 


Access Node 


2 


Hub Access Node 


3 


Collocated Subtended Access Node 


4 


Remotely Located Subtended Access Node 


5 


Subtended Remote Access Node 


6 


Subtended DLC Located Access Node 
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Aggregated DLC Located Access Node 



4.2.6 U Interface 
4.2-6.1 Functionality 

The U interface is defined as the interface between the Access Network and the CPN. This interface refers to 
the area between the CPN where the ATU-R (DSL Modem) is located and the Access Network where the 
Access Node is located. The U interface includes the capabilities and protocols that cross between the Access 
Network and the CPN. 

4.2.6.2 Communication Protocols 

As shown in Figure 14 the U interface defines the interworking between the CPN and the Regional/Access 
Network. This interface MUST^ support the bi-directional delivery of data for all the new product and service 
definitions as well as for existing (legacy) products and services. 
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Loop 



Regional / Access Network 




U 



Figure 14 - U Interface 

Although the first Network Element connection in the network is at the Access Node, the U interface MUST^j 
support the transparent flow of protocols from the DSL Modem to the BRAS. 

♦ The U interface MUST^ support at least one ATM AAL5 PVC per CPN using PPPoE and/or IP over . 
Ethernet (IETF RFC 2684) configured using DHCP (for IP over Ethernet). Although the target architecture 
to support QoS enabled IP services seeks to utilize a single ATM AAL5 PVC per CPN, it is recognized that 
certain required network element features identified in this document, have yet to be developed. In 
particular, dynamic packet fragmentation/MTU sizing in the CPE (needed to control jitter and delay for short 
packet/high priority applications) may trail the availability of other required network element features. In 
order to meet the demands of service descriptions previously identified in an acceptable timeframe, a 
second ATM PVC may be provisioned as an interim solution to provide a means to separate those 
application flows having tight jitter and latenny requirements. This second PVC will require that DSL 
modems support multiple PVCs. In the event that 2 PVCs are supported provisioned, it is desired that they 
eeutel be treated as a PVC bundle as this feature is made available. Additionally the PVC bundle standards 
need to be enhanced to support bridged Multi-service traffic. 

♦ The U interface MUST ra support Diffserv Code Points (DSCP) per IETF RFCs 2474 and 3260, enabling 
application-layer QoSaccess. 

♦ The U interface MAY^ support signaled QoS, based on RRP protocol as described before. 

♦ The U interface MUSTpoj support the ability to dynamically push IP routes back to the customer PC or 
Routing Gateway. Thus, RIPv2 will be used to provide routes to the RG. The RG is not expected to provide 
routes to the WAN. 
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The communications protocol stack is shown in the following figure. 
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Figure 15 - U Interface Protocol Stack 

Network Layer 

The network layer interface MUSTpi] support IP version 4 in accordance with IETF RFC 1042. 
The network layer MAYpg support IP version 6 in accordance with IETF RFC 2460. 

The network layer interface MAY m support IP precedence based on Diffserv Code Point (DSCP) markings, in 
accordance with IETF RFC 3140. 

The network layer interface MAY^j support IP QoS types based on RRP in order to receive BoD grants 
independent of precedence or assured resources, dynamic admittance to a traffic precedence class, assured 
bandwidth, or some combination of these. 

The network layer interface MUST [85] support PPPoE per IETF RFC 251 6. 
Data Link Layer 

The data link layer MUST I86) support Ethernet encapsulation in accordance with IETF RFC 2684. 
The data link layer MUST^ support ATM in accordance with ATM Forum standards. 
Physical Layer 

The physical layer interface MUST [88] support G.dmt, and its related standards. 



4.2.7 Customer Premises Network 

The Customer Premises Network (CPN) is defined at its highest level as the location where the ATU-R is 
located and terminates the physical DSL signal, and where the subscriber's computers and other devices are 
interconnected.. The initial DSL deployments focused on single user architectures where the CPN constituted a 
single PC connected directly to a DSL modem. This paradigm of service will continue to be supported and 
improved, but must be extended to support advanced features that go beyond the single user model. To 
support enhanced features (multi-user, gaming, VoIP, video, etc), the CPN must evolve to support the 
networking and management of devices and services within the home or business location. 

From a network perspective, the CPN is the ultimate target of the services provided by the Service Provider 
(NSP or ASP). The CPN includes the networking environment and protocols that are resident in the premises. / 
CPN may imply coexistence of different link and physical layer technologies such as radio, power line 
transmission and Ethernet, but is assumed to have access to outside networks (via DSL). The terms devices 
and appliances refer to the collection of end terminals that can reside on the CPN, either temporarily (laptops, 
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palm pilots, foreign devices etc.) or permanently, such as desktops, security, and climate control systems. 
Devices may or may not be individually addressable and reachable from other devices, inside or outside the 
CPN. Some devices may communicate with proxies that then can relay or translate state or configuration 
information for these end devices. 

4.2.7.1 DSL Modem 

Description 

The DSL Modem contains the ATU-R and terminates both DSL and ATM. It may or may not be integrated with 
additional Routing Gateway (RG) functionality, if it is not integrated, it will be used in a mode that is referred to 
as a simple bridge modem. 

Capabilities 

The capabilities of the DSL Modem in support of this WT-081 proposed architecture MUST™ include but are 
not limited to the following: 

♦ 2 ATM AAL5 PVCs - in order to be able to support the U interface service option of using 2 PVCs as 
described in 4.2.6.2. Note that in practice, DSL modems will likely have additional service drivers that 
would require them to support additional PVCs. ' 

♦ UBR, UBR+ and VBR-rt ATM classes of service 

♦ Per-VC queuing, separate priority queues for ATM classes of service 

4.2.7.2 Routing Gateway 

Description 

CPN architectures typically leverage a Routing Gateway (RG) device that provides functionality beyond that of a 
basic DSL modem. The RG is a device for providing enhanced services within the CPN. The RG may or may 
not be integrated with the DSL modem function. In the integrated scenario, the device terminates the DSL signal 
from the network and provides an interface to other equipment located within customer premises. In the non- 
integrated case, the RG is physically separate from the DSL modem and adds functionality to the CPN 
independent of the DSL modem. Since the integrated RG has knowledge of the CPN and its access to external 
networks, it enables tighter control of QoS for real time applications than may be possible in a non-integrated 
architecture. Both integrated and non-integrated RG are supported in this specification. 

Capabilities 

To support this QoS-enabled architecture, the capabilities of the RG MUST include but are not limited to the 
following: 

. ♦ IP routing between the CPN and the Access Network m 

♦ Multi-user, multi-destination support: Multiple simultaneous PPPoE sessions (started from the RG or from 
devices inside the CPN) in conjunction with non-PPP encapsulated IP (bridged) sessions per IETF RFC 
2684. „ 

♦ Network Address Port Translation (NAPT) ^ 

♦ Local DHCP m 

♦ Support for major applications and protocols in the presence of NAPT and firewall (e.g., SIP, H.323 : IPsec) 
m 

♦ Dynamic MTU negotiation^ 

♦ Packet segmentation based on traffic/queue type m 

♦ PPPoE pass though^ 

♦ Multiple queues, with the appropriate scheduling mechanism. m 

♦ IP QoS 

♦ Classification, scheduling and shaping of IP flowspgj 

♦ Diffservj 100 } 

♦ Management interface[ 10 ij 
. ♦ RRP signaling f10 2j 
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♦ Support for real time services (Voice, Video) [10 3] 

♦ Re-classification capabilities^] 



If 2 VCs are provisioned, support the mapping between Diffserv Code Point (DSCP) and a specific PVC 
(Using a PVC bundle is the desired way to meet this requirement) [10S3 



4.2.7.3 Networking Technologies 

Description 

The CPN will support the transparent transmission of IP packets. It is expected that the CPN will be a hybrid of 
technologies that may include Ethernet, phone line networking, power line networking, wireless networking, and 
others. 

4.2.7.4 LAN Devices 

Description 

Devices inside the CPN that are served by -the DSL Modem and RG, and connected by the various Networking 
Technologies are referred to as LAN Devices. These may include, but are not limited to, PCs, laptops, 
networked set-top boxes, and Internet Appliances. 

4.2.8 T Interface 

4.2.8.1 Functionality 

As shown in Figure 16, the T interface defines the interworking between the DSL modem/RG and the LAN 
Devices. This interface MUST I106 ] support the bi-directional delivery of IP packets between the RG and other 
CPE as well as the ability to assign addresses to other CPE using DHCP. The other major functional 
requirement placed on the T interface includes identifying and supporting "QoS flows" as defined in Section 5. 
The primary goal of this interface is to facilitate seamless transmission of IP packets in both a best effort 
approach as well as maintaining predefined QoS behavior (Diffserv) or establishing dynamic QoS behaviors 
through a signaling mechanism (RRP). 



NID 



Analog 
Phones 



DSL 
Modem 



Routing 
Gateway 



Gaming Consoles 
Personal Computers 
Set-top Boxes 
Printers 
Scanners 
Cameras 
Web Appliances 

IP-Phones 
IP-Centrex Phones 
Home Automation Equipment 



v 



Customer Premises Network 



Figure 16 - T Interface 
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4.2.8.2 Communication Protocols 

Network Layer 

The network layer interface MUST [107] support IP version 4 in accordance with IETF RFC 1042. 

The network layer MAY [10 8] support IP version 6 in accordance with IETF RFC 2460. 

The network layer interface MUST [109) support IP precedence based on differentiated service (Diffeerv) code 
points in accordance with IETF RFC 3140. 

The network layer interface MUST [110] support IP QoS types based on RRP in order to receive BoD grants 
independent of precedence or assured resources, dynamic admittance to a traffic precedence class, assured 
bandwidth, or some combination of these. [To be consistent with the RRP descriptions for the A10 and U 
interfaces, the MUST should be replaced by a MAY.] 

Data Link Layer 

The data link layer MUST [111} support Ethernet in accordance with IEEE 802.2/802.3 (Ethernet) and as shown in 
Figure 17. 

The data link layer SHOULD [1l2) support Ethernet virtual LANs (IEEE 802.1Q). 

The data link layer SHOULD [113] support Ethernet precedence of LAN trafTu>(IEEE 802.1D/Q). 

The data link layer MUST [114] support PPP over Ethernet in accordance with IETF RFC 2516 and as shown in 

Figure 18 

Logical Link Controller (LLC) Sublayer 

The logical link controller sublayer subinterface MUST [115] support Ethernet in accordance with IEEE 802.2. 
Medium Access Control (MAC) Sublayer 

The medium access control sublayer subinterface MUST [116] support Ethernet in accordance with IEEE 802.3. 
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Figure 17 - IP over Ethernet 
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Figure 18 - IP over PPP over Ethernet 



5 QUALITY OF SERVICE 

5.1 Introduction 

DSL architectures and products are predominately engineered for the support of best effort Internet traffic. Many 
NSPs desire the ability to improve their best effort product by using different levels of over subscr.pt.on. 
Additionally, there are other market drivers pushing the Regional/Access Network to support drfferentiated 
services that require functionality beyond a best effort grade of service. Such services include telephony ^ video 
services, gaming, bandwidth on demand, and corporate VPN access as referenced in sec .on 2.2. In order to 
support IP services effectively, the network MUST, 117) be IP aware and prov.de support that scales as the 
number of DSL subscribers and the number of applications per subscriber increases. 



5.1.1 Goals 

The goal of this section is to describe the mechanisms for introducing: 

♦ A method for providing differentiated best effort traffic engineering 

♦ Per flow IP QoS into the Regional/Access Network 

Both of these goals leverage the existing capital investments yet effectively meet the goals for supporting 
differentiated non-real time and real-time IP applications- 
One goal of the architecture is to enable more flexible bandwidth allocation to customers. It is a goal to allow 
both the customer and the various Service Providers to participate in defining the bandwidth that will be made 
available to them via DSL. This bandwidth can be provided at different rates not only at JJL 
service orders, but also on demand in near real time using mechan.sms like turbo ! buttons at NSP or ASP web 
interfaces, or by using signaling protocols. It should be noted that this is still best effort bandwidth - there .s no 
guarantee that an application can make use of the maximum bandwidth,.in other words there are no throughput 
guarantees - only that the possible maximum rate might be increased. 

Real-time applications have concerns beyond bandwidth, like jitter and latency, which become harder to 
manage when the DSL line rate slows down. Other applications, while may not be real time have delivery 
requirements (no packets dropped) that cannot be assured by bandwidth alone. It .s a goal to manage multiple 
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applications over a small number (1 or 2) of ATM PVC(s) between the ATU-R and BRAS and provide the 
characteristics that both real-time and non-real time applications require. 

5. 1 .2 Assumptions 

Existing Regional Networks have a large embedded base of ATM equipment that is not IP aware. This 
equipment will be leveraged to the extent that it is technically and economically feasible. 

5.2 Best Effort Traffic Engineering 

Today's DSL access and Regional Networks are typically engineered to a single over subscription ratio picked 
by the various providers. This has served the market well, but may need to be enhanced as service diversity 
expands and scope broadens. The concept for best effort traffic engineering is that an NSP might be able to 
select an over subscription policy, and that the various NSPs can use that as a tool for providing different grades 
of service, even in an otherwise best effort model. Using this feature, one NSP may opt for highly over- 
subscribed infrastructure in order to provide an extremely cost-effective service, while a second NSP might 
choose a much less over subscribed approach in order to provide a better user experience or a premium 
service. 

5.2.1 Theory of Operation 

Best effort traffic engineering (TE) makes use of MPLS TE, ATM VP or VC, and L2TP features in order to 
provide a specific over subscription rate for that NSP. 

As shown in Figure 19, traffic flowing between NSP-j and CPNh is shaped to a large asymmetric configuration 
through the Regional/Access Network. At the same time, traffic flowing between NSP 2 and CPN 2 is shaped to a 
smaller symmetric configuration. Finally, ATM or Diffserv techniques can be used at the A10-NSP interface in 
order to divide the total bandwidth at the interface among potentially disparate tunnel types that traverse it. 
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Figure 19 - Best Effort TE 



5.3 QoS Architecture - A two-phase approach 

While a signaled per flow IP QoS mechanism is the ultimate goal of this architecture, the technical and 
economic feasibility of such a build out can not be justified in the near term. Instead, a 2-phase approach is 
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suggested that leverages incremental IP awareness associated with ATM level traffic engineering. In the first 
phase IP aware network elements are added to the network that in conjunction with ATM traffic engineenng 
can manage IP flows through non-IP aware devices. The Diffserv model is leveraged to pnoritize and shape 
traffic through ATM devices. The bandwidth that a subscriber receives will no longer be determined by the DSL 
synch rate alone. Instead, both the physical and IP layers will be leveraged. Most importantly, phase 1 
significantly increases the IP layer functionality of the Regional/Access Network while not requinng massive re- 
deployment of capital and re-engineering of the network. 

Phase 2 however, will require more enhancements to the Regional/Access Network by eliminating or 
enhancing some ATM elements/functions and further increasing the IP capabilities. IP signaled QoS is 
introduced in this phase. 

5.3.1 Phase 1 QoS Mechanisms 

Phase 1 largely leverages the existing broadband Regional/Access Network as shown in Figure 3. This network 
is generally IP unaware. In order to efficiently add IP awareness to the network without upgrading the ATM or 
Access node base, two enhancements are required: Within the network the BRAS is leveraged to provide IP 
aware handling of traffic and, similarly, at the customer premises new CPE capabilities are deployed. 
One of the goals of this architecture is to provide differentiated services with IP QoS over a non-IP-aware layer 2 
network If the layer 2 QoS features are left unused, then traffic from different IP QoS classes is put in the same 
queues in the layer 2 nodes. Since the layer 2 nodes cannot identify the different IP. QoS types within a single 
queue, congestion MUSTma be avoided in all layer 2 network elements at all times, if IP QoS is to be retained. 
Furthermore IP QoS types that ofFer jitter management will also require that not only congestion is avoided in 
the L2 queues but also that significant queuing is avoided as well. By avoiding , congestion in the layer 2 
network its role is being reduced to simple transport, and the switches are modeled like simple multiplexers. 
This means that the full buffering mechanisms in the layer 2 nodes are not used. Avoiding downstream 
congestion in the layer 2 network can be achieved by giving the BRAS full control or awareness of a logical tree- 
based network topology. This topology is based on the actual physical topology, but excludes resources that are 
used by other services (see section 5.3.1 .2). The BRAS MUST [119) be aware of all potential congestion points in 
this topology, as well as the trunk bandwidths and DSL synch rates. The BRAS MUST [120] make sure that no 
more traffic is inserted in the layer 2 network than is allowed according to its knowledge on the logical topology. 
This can be achieved using a hierarchical scheduling mechanism. Avoiding upstream congestion in the layer 2 
network is achieved in part by the natural over-provisioning the upstream links due to the asymmetric nature of 
ADSL and also in part through the use of RED and WRED techniques in the BRAS to police the upstream 
traffic. The RG just has a view of its own DSL line, and doesnt know about the DSL lines that belong to other 
RGs. 



When a subscriber purchases a differentiated service, this service MUST |12 i] flow through the BRAS. To support 
differentiated services, the BRAS preserves IP QoS downstream through the access node and to the customer 
premises by means of packet classification, traffic shaping and hierarchical scheduling based on the logical tree- 
based network topology between the BRAS and the RG. 

Once the BRAS is capable of managing the traffic flow through the access node, there is no need for access 
node to restrict a subscribers connection speed at layer one (ADSL synch rate). Instead, the access node 
should allow the ATU-R to synch up at its maximum rate. Access sessions will now be shaped and rate limited 
by the BRAS and can allow for multiple sessions to be individually shaped based on the subscnbed service. 

The BRAS MUST, 122 j support packet classification and scheduling in accordance with Diffserv. 
The BRAS MUST |123) support hierarchical shaping and scheduling for the control of traffic through the 
access node and any other intervening devices that do not have IP awareness. Concrete implementations 
of hierarchical scheduling MUST 112 4] be resource efficient in the sense that any traffic MUST 1125) be capable 
of using the bandwidth that has been allocated to that traffic class, fl thought that originally the idea was to 
achieve resource efficiency such that e.g. BE traffic can o ccupy 3W that has been allocated to EF Traffic. 
but is not effectively used bv EF applications. Mav-be the following t ext could captu re tnis ioea: "Concrete 



♦ 
♦ 



28 



DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services WT-081 

implementations of hierarchical schsrt. .linn mi ist ha resource efficient in the sense that bandwidth that h flc 
been allocated to a given traffic class h ut is not effectively used bv that traffic class at a given momen t in 
time, can be occupied by other traffic classes. 1 " 

The effectiveness of using hierarchical scheduling across non-IP aware devices decreases as the number of 
devices and the amount of non-BRAS controlled traffic increases. As a result, the BRAS function SHOULD, 12B1 
be located as dose to the access node as possible from an ATM hop perspective. The daisy chaining SHOULD 
2 L'^r^ 66 3 pth 0f more than t* 0 A ™ switching/multiplexing points in the Access Node. Additionally if 
me BRAS does not include ATM switching functions, then an additional layer of hierarchical scheduling 
MUST (128) be used to manage the trunk to the ATM switch. The BRAS function MAY ri2gi be integrated into the 
access node. 

In order to preserve an IP flow's characteristics, the customer CPE MUST [130J be involved in the QoS 
architecture. This is especially true when dealing with traffic destined for the upstream DSL connection This - 
connection is typically the slowest link and most likely to incur congestion and add delay and jitter within the 
^ ICe hI° T amiain fair J )Ut effSCtive throu9h put over this link RG MUST ti3D support packet classification 
and type aCCOrdance ^ Diffserv - ^ RG MUS Tt«J su PP°rt fragmentation based on queue status 

1116 .^KS ° SL customer is connected to the Regional/Access Network via a single ATM AAL5 PVC This 
single PVC should be leveraged to the extent possible using the capabilities described above. Although the 
target architecture to support QoS enabled IP services seeks to utilize a single ATM AAL5 PVC per CPN it is 
recognized that certain required network element features identified in this document have yet to be developed 
In Particular, dynamic packet fragmentation/MTU sizing in the CPE (needed to control jitter and delay for short ' 
packetyhigh pnority applications) may trail the availability of other required network element features In order to 
meet the demands of service descriptions previously identified in an acceptable timeframe, a second ATM PVC 
V\J 2F P rovisi0ned as an interim solution to provide a means to separate those application flows havinq 
tight jitter and latency requirements. This second PVC will require that DSL modems support multiple PVCs 
For the service model proposed in this document, the number of PVCs per customer SHOULD NOT, 134) exceed 

To support bandwidth on demand products or other differentiated services that implicitly require additional 

bandwidth on demand, a subscriber's access sessions SHOULD, 135 i be shaped and policed by the BRAS and 

RG instead of solely by the DSL ATU-R and ATU-C. This change is accompanied by changing the ATUs to 

allow them to synchronize at or near their maximum rate. Since we allow for multiple simultaneous access 

sessions, it MUST t136] be possible to modify the shapers and policers on one or more sessions at the same time 

I he policy data for the classification and shaping of traffic at the RG is provided at service configuration and is 

not a real time capability. The policy data for the classification and shaping of traffic at the BRAS can be 

P ™fr a l l 6 ™ 06 configuration or may be dynamically configured via a Common Open Policy Service-like 
(COPS) interface. 

Phase one assumes that the Regional/Access Network provider has established an IP-based architecture 
similar to that shown in Figure 4. This figure can be combined with Figure 2 in order to support the end-to-end 
view of the QoS-enabled network that follows. That combination is presented in Figure 20 
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Figure 20 - QoS-enabled Network Topology 

The two critical points where IP-QoS is managed are the BRAS and the CPE (RG). Intervening elements (like 
DSLAMs) are not envisioned to become layer-3 routers, and this architecture assumes that they will hot be 
layer-3 aware when they manage congestion. This arrangement supports multiple business relationships and 
provides connectivity for various users to access various services without requiring all services to be provided 
by a single provider. 

Phase 1 is characterized by Diffserv, but can also be further subdivided in to 2 sub-phases. The first sub-phase 
(1 A) would describe a time when Diffserv would be provided through static provisioning. The second sub-phase 
(1B) would describe a subsequent time with a dynamic mechanism for changing the Diffserv Q6S parameters 
through the use of a policy-based networking enhancement. 

Phase 1A 
Assumptions: 

• In this phase there will be multiple BE NSP connections with few (1 or 2) EF sessions for real time 
applications (voice, Video conferencing). There will be little or no AF traffic - as applications would 
have to make use of a static pre-configured AF classes rather than requesting one that suits the 
application. 

• Only one EF application is guaranteed at a time (user performs the CAC across real time applications). 
Within an application domain it is the application's responsibility to perform the CAC. 

• Classification is performed at the RG on a session basis or accepted via markings attached to packets 
by the CPE 

• Performing dynamic, per-application classification requires a 5-tuple classifier to be pushed down to the 
RG and is not likely in the short term. 

- • The DSLAM modems are allowed to sync near or at the max rate both upstream and downstream. 

• Hierarchical scheduling is performed at the BRAS to provide IP QoS congestion mechanisms for the 
downstream path. Similar policing is performed in the upstream path. 

• Packet-by-packet QoS requires being in the PTA (or bridged 2684) model at a given element. 



Characteristics: 

• Multi-user multi-destination is supported 

• IP QoS is managed at the RG and BRAS 

• The RG and BRAS are configured with common set of traffic profiles 

• RG is configured by manufacturer or during installation (install CD) 

• Statically assigned BE and EF queues will be supported in the RG. 

o Optional are statically assigned AF queues that could support 3 or 4 popular streaming 

arrangements or potential Gold/Silver/Bronze services. This option will require defining Diffserv 
classes that will be applicable across envisioned future services. 
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. Profiles define what rate traffic should be shaped to and what queuing behavior should be used. 
. Profiles will also determine the valid DSCPs. 

. A small number of shapers will be defined for the various connection speeds (e.g. 1 .5x265, l ,5x x*. 

. ItssSs IreSdually shaped based on profile and share *e aggregate DSL synch i J^JMhettW 
BW per profile exceeds the available sync rate then they share the BW in a 1a.r" manner among similar 
QoS service classes. . . . , ,„„ 

. If the RG initiated the session, and it is authenticated, then it is told which P^nrnd profile tc .use. 
Various potential protocols and mechanisms to do this have been discussed I at the DSLF. Note a 
CPE device behind the RG initiates a PPPoE session then it rema.ns PPPoE through the RG, and .s 
BE traffic by definition. (Even if it becomes a PTA connection at the BRAS) 

. |n either a PTA or L2TP model the BRAS will police traffic in the upstream direction and shape traffic in 
the downstream direction. 

. BRAS shaping, policing, and marking is done on a per session basis, not per bp^Hwm. the 
diffserv queues can be arranged within an access [What dogs !acoess: msan here? Is it access 
SEqS KhwtauB aggregate service classes can be provided to applications that indicate which 
. Srfiir^ce they desire The application needs to set the DSCP property in order to make use of 

this ^ nc ^ , n n end to _ end pp p sessjon js gjven a be treatment, but can be shaped (e.g. 1 .5x256). 
o A single, additional PPP or 1483 session is used to access the ASP network. 
• The BRAS profiles are updated through provisioning, not signaling. ■ _ 

. New profiles are added/updated in the RG by the customer, manually configuring the device or by 

downloading a new SW image 

Phase 1 B: 
Assumptions: 

. Builds on the capabilities in phase 1A »u„ or 

. This phase enhances the granularity of the classification and populat.cn of polices in the RG. 
. Multiple sessions to multiple destinations, each with multiple applications that may require different QoS 
treatment 




Policy 
Server 



Figure 21 - Phase 1 with Policy-based profiles 
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Characteristics: 

. When an NSP access session is authenticated the NSP MAY provide a profile indicator associated 

with that session in its response to the BRAS. 
, Once the BRAS receives the profile indicator, it retrieves the full profile from the Policy Server. Similarly, 

information is sent to the RG when it requests a profile. This step allows coordination among NSP and 

ASP rASP" should probably be "access provider"?] profiles. 
. No single ASP authenticates the ASP access session, so a profile for that session is put together by 

the Policy Server and is based on various ASP subscriptions associated with that acces s [What is the 

meaning of "access" here? Is it "access session"?! . 
. ASPs can update the profile either through subscription or through a dynamic protocol. 
. Subscription profile information as well as DSL sync rate and user preferences are stored in the Policy 

Server and accessed using LDAP. 
. The Policy Server is responsible for managing potentially conflicting ASP and NSP profiles and 

subscriptions and also creates billing data for services. 
. The profile is populated in the elements in near-real time (no reset or "reboot" required). 
. Diffserv marking and queuing behavior on RG is performed on 5-tuple matching (SA, DA, SP, DP PI) 

as well as the mapping of existing marks and access sessions into various "equivalent* classes. For 

example, PPPoE access through a RG will continue to be given BE treatment. 



5.3.1.1 Diffserv Requirements 

RG 

The RG requirements below only apply to the support of differentiated services. 

The RG MUST 1137) be the central point for controlling traffic within the customer premises and traffic destined for 
the Access Network. 

The RG MUST (13 s| support Diffserv marking and reclassification in accordance with IETF RFC 2474. 
The RG MUST I139 , support Dtffserv queuing for the Assured Forwarding (AF) and Expedited Forwarding (EF) 
classes in accordance with IETF RFC 2597 and IETF RFC 3246 for carrying real time traffic. The exact AF 
classes supported will be described in a future document. 

The RG MUST [140] support multiple queues with the appropriate scheduling mechanism to effectively implement 
Diffserv queuing behaviors (e.g. strict priority, Weighted Fair Queuing). 

The RG MUST, 141) be configured with the classification parameters for mapping traffic into a given Diffserv Per 
Hop Behavior (PHB) during service configuration. 

The RG MUST, 14?I support fragmenting large data packets in the Best Effort (BE) and AF queues when packets 
are present in the EF queue. 

The RG MUST 1143] support an EF window timer. The EF window timer is required to support real time 
applications that exhibit a more bursty nature (e.g. VoIP with silence suppression) so that BE and AF packets 
continue to be fragmented even when EF packets are not present. 

When no packets are queued in the EF class for a duration longer that the EF window timer, the BE and AF 
packets MUST NOT [144) be fragmented unless required for other reasons (negotiated MTU size). 
If multiple PVCs are provisioned at the ATU-R. the RG MUST (1451 support the mapping between a Diffserv Code 
Point (DSCP) and a specific PVC. (Using a PVC bundle is the desired way to meet this requirement.) 

BRAS 

The BRAS MUST l146) support Diffserv marking and reclassification in accordance with IETF RFC 2474. 

The BRAS MUST, n47) be able to police the use of DSCPs received from customer traffic and remark traffic as BE 

if it does not match the customer profile data. 
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The BRAS MUST [148J support Diffserv queuing for the Assured Forwarding (AF) and Expedited Forward™ #pn 

tSSHSSS^S ,E T T° 2597 and ,ErF RFC 3246 - n° RFC 324 * on » 5^SSte f 

defines a PHB m which Fr packets are guarante ed to receive sgrvtai at or above a confin ed m l an H 

l!!! !i , P '. n f ! P^ en J^itPrt„rP? Is thgre a sinnl* aT , reaate configure mtp P a , ttjSjgg ~ 
phys cal output port in the BRAS or is there a hisVa^hv nf pp ^ aur&6 ^ „ n tn thp jjjggff, ^ 
HA) or even apphcata level (1 BP] The exact AF classes su pported will be described in a f^e ^cTmen 

n^X? d6fin ^ **** the ^ * the DSLAM «™«»* between the B^d the aS' 
node in affect managing the access node's downstream bandwidth. 

^L B r SSrS ST|1491 SUPP °u mulliple queues per user ^ appropriate scheduling mechanism to effectivelv 
implement Drfiserv queuing behaviors (e.g. strict priority, Weighted Fair Queuing). eftectjvely 

S*5£ S the T SSe^or Pin9 ° f DSCP t0 MPLS LSP - VLAN ' A ™ VP ' ° r 0lher ** en ^-9 
S3^'^^5^ ^ date Pa ° kete in lhe BeSt Effort ^ and AF queues when 
2r!li^LTJlK UPP ° rt a u EF Wind0w timer ^ EF window « mer is «Mred to support real time 

ISIZ°pSSL^ S ^ ^ P fi r ° V D ^ ne S', the BRAS MUST ' 1 ^ Support the mappin 9 between a 
requ^ement.) ^ ^ ° VC ' (Using 3 PVC Dundle is *» desired wa V to mee * this 

[Do we need a requireme nt that " the B RAS MUST defragment upstream l^p ackete^] 

5.3.1.2 Traffic Engineering Requirements 

Sing m^tBS^T 6 d ° WnStream IP * affic ***** 2 devices using the hierarchies. 
etem^Tn£2^£ I have awareness of all the traffic that is traversing those layer 2 

22ESi 1 06 accornpllsned ,n 2 ways. The first and most straightforward method is for all traffic 

ffSSSS^r" 0 * t0 , fl ° W lhr ° Ugh lhe BRAS enab,ing i{ to mana 9 a t"e traffic «^T«b case 
ZlrH rill ? schedu, ' n 9 model in the BRAS will be based on the full downstream trunk bandJShs an I DSL 

of SeBrSs M?ST S tel 2 S2! Cfl r thr ° U9h lhe BRAS ' the reS0UrCes that are not tSSrSB^ 

bnSu^r th re^^ I SS!^ be TIm? USin9 lhe h J erarchi0al SOhedu,ing modeL Th * ^c that 
that the BRAS fe^Z?J ?e MUST W be traffic engineered in a way that it cannot consume resources 
mat the BRAS is controlling. Eng.neenng around the BRAS incurs risk and must be done with care. 

5.3.1.3 Admission Control 

Network level admission control is not required in this phase. Admission control MAY, 1581 be provided at the 

cu^pre^ 

5.3.2 Phase 2 QoS Mechanisms — 

55 sectK induHpS tT^? 86 * ^ Q ° S enh ancements is not fully defined in the following section. 
I his section is included for illustrative purposes and will be fully defined in future documents. ■ 

to +Z£S^^ capabilities in the Regiona^Access Network. Phase 2 continues 

tfw derate sS T^fnn^nil 6 ' Q ° S managerS ° f 1116 access network - Rath er than simply managing 
ensuSn E 9 ° f DrffSerV resources . the BRAS will be able to perform per flow admission control 
SIS ^ are n6Ver ° Ver b0oked ' Diffserv t0 he used beyond the BRAS for 

SEP r ^ S T S - ^f" 9 Per fi0w resource reservation iimi4ed to ^ access porta, offlie R^foSl/Access 
Network will hmrt scalabiirty/performance issues known with prior end-tc-end reservation schemS 
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In this phase: 

Applications, located in any of the reference networks, request service or resources of the 
Regional/Access network (e.g. through RRP). 

The RG and BRAS are involved in requests for services and resources in the network based on a per- 
application need (e.g. they monitor or proxy RRP messages). 

The BRAS acts like an RSVP border proxy and queries the Policy Server. It responds based on the 
network availability of traffic engineered resources (MPLS - TE, ATM VP, etc) and customer profile. 

QoS service profiles can be applied to the BRAS and RG based on the requested application need. 

5.3.2.1 Signaled QoS Requirements 

[What will happen to these requirements when phase 2 move s to an annex? 1 
BRAS 

The BRAS MUST |159] support a RRP for the assignment of resources. When resources are not available at any 
point under its control the BRAS MUST [160J reject the request and provide feedback' to the initiating host. 
The BRAS MUST, 161 , know the DSL sync rates of the ATU-Rs that are connected to the access nodes that it 
manages. Based on a given ATU-R's DSL synch rate and customer profile the BRAS MUST [162] manage the 
admission of sessions to that customer premises. An external policy/management server MAY feed this 
information to the BRAS. 

The BRAS MUST !n63] be able to intercept RRP and other application layer (e.g. SIP) messages that are not 
addressed to it and use these messages in making admission decisions. [At this point I see two alternatives 
which haven't been fully discussed during the DSLF meeting s : an in-band signaled approach based on BRAS 
interception, and an outof-band approach with an explicit B2B interfac e betw een the NSP/ASP and 
reaional/access provider. Is it the intention of WT-081 to expr es s a prefe rence for the m-band case?] 

The BRAS MUST !164] support mapping reservation requests into Diffserv PHBs and managing the PHBs as 
reservable resources. 
CP E fRG instead of CPE?1 

The CPE requirements below only apply to the support of differentiated services. 

The CPE requesting differentiated services MAY m be integrated with the ATU-R. Non-integrated CPE devices 
will also be supported (e.g. IP Phones, PC running video conferencing software, set top boxes, etc). 
The CPE MUST, 16 6] support IP layer signaled QoS via RRP. These messages MUST {167 ] be addressed to the 
destination host and MUST NOT (168] be addressed directly to the BRAS. 

The CPE MUST NOT( 169) make any admission decisions. 

5.3.2.2 Diffserv Requirements 
BRAS 

The BRAS MUST [17C » conform to the requirements listed in section 5.3.1 .1 

The BRAS MAY, 171) accept policy information regarding how to manage Diffserv resources from an external 

entity. 

CPE 

The CPE MUST| 172) conform to the requirements listed in Section 5.3.1 .1 

If the signaling messages indicate the DSCP to be used by a session requesting access, the CPE MUST l173l . 
use the specified DSCP. 

The CPE MAY, 174] accept policy information regarding how to manage Diffserv resources from an external 
entity. 
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5.3.2.3 Traffic Engineering Requirements 

The RRP mechanism described only has resource knowledge of the local access node ["network" iso "node*?] | 
and does not have an end-to-end picture of the connection. As a result, the interconnection network within the 
Regional/Access Network (beyond the BRAS) MUST [17 5j support traffic engineering to provide support for 
enhanced services. It is expected that within the core of the Regional/Access Network that aggregate traffic 
engineering techniques can efficiently serve the needs of enhanced applications. 

The Regional/AcGess Network MAY [1763 support MPLS TE. 

The Regional/Access Network MAY [177] support ATM level TE. 

The Regional/Access Network MAY (178j support Diffserv. 

5.3.2.4 Admission Control 

Per-fiow admission control MAY {17g] be performed at the BRAS. Admission decisions are made based on 
resource availability AND subscriber profile data. Both of these parameters MAY [180 ] be.sent to the BRAS via an 
external policy/provisioning server. 

Application level admission control MAY [181] be~applied in addition to the network based admission control. 

6 SERVICE LEVEL MANAGEMENT 

6.1 Introduction 

Service Level Management is intended to provide 3 levels of benefit - increasing over time: 

♦ To provide a list of the salient network performance and operational metrics that might be used, in a Service 
Level Objective (SLO) or Service Level Agreement (SLA). 

♦ To provide a standard definition of such metrics so that its meaning would be common when used by 
various providers. 

♦ To provide extreme values that are driven by architectural considerations where applicable. For example, 
while it is NOT the intention of this document to set the SLO or SLA for Network Delay (Latency), any 
network that purports to support Voice over IP (VoIP) will need to have a maximum delay that is within the 
bounds necessary to support VoIP. 

6.2 Network Performance Metrics 

1 . Network Availability - The percent of time that the Regional/Access Network is available for subscribers to 
connect. This metric is defined on some time basis, such as a month, a week, or a year. An SLA should 
also specify not the entire network but the section of the network for which the Regional/Access Network 
Provider is responsible. For example, the Regional/Access Network Provider is not responsible for NSP 
problems. 

2. Network Delay (Latency) - The time it takes for a data packet to traverse the Regional/Access Network, 
from end-to-end or edge-to-edge. Latency is defined in milliseconds and can be a one-way or round-trip 
delay. 

3. Message Delivery - The ability of the Regional/Access Network to transmit traffic at the negotiated speed. 
Some applicable measurements are packet loss). These metrics must have a time base as well. 

4. Network Jitter - The variance of network latency. Jitter is defined in milliseconds. 



6.3 Operational Metrics 

1 . Mean Response Time - The time it takes the Regional/Access Network Provider to respond to submitted 
reports of trouble 

2. Mean Time to Restore Service - The measurement of the Regional/Access Network Providers ability to 
restore service within the negotiated interval 
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3. Ordering System Reliability - The measurement of the consistent availability of ordering system. 

4. End-User Installation Guarantee - The measurement of the Regional/Access Network Provider's ability to 
meet negotiated order due dates. 

7 SERVICE MANAGEMENT 

The architecture proposed in this document clearly needs management systems to provide the controls 
necessary to support the underlying service "building blocks". The following lists are examples of new data 
points that management systems MUST [18 2] support. Network elements and Service Providers will use these 
new data elements for service provisioning and data delivery. It is expected that the Operations and Network 
Management working group of the DSL Forum will provide contributions to augment this section. 

7.1 Subscribers 

Because of the changes in how DSL is provisioned and managed, there are a number of new data points that 
MUST [183] be tracked for each subscriber. Among these are: 

♦ Maximum sustainable subscriber bandwidth 

♦ Maximum number of sessions allowed 

♦ Permitted destinations 

♦ Default protocol 

♦ Default destination 

♦ Default bandwidth 

♦ Single host or subnet needed 
♦ 



Restricted subscriber (single destination only) 



♦ Total reserved bandwidth 



7.2 Service Providers 

Because of the changes in how DSL is provisioned and managed, there are more details needed per Service 
Provider. When various choices listed for an option, these are to be considered as examples only and not a 
definitive list of the choices for a given option. 



♦ Minimum bandwidth needed 

♦ Minimum QoS level 

♦ Various protocol metrics 

♦ Subscriber protocol (IP, PPPoE) 

♦ Protocol (IP, L2TP, ATM) 

♦ Authentication 

♦ IP address assignment 

♦ Transport 

♦ Maximum simultaneous sessions 
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^oBB Voice over Broadband 

VoD> Voice over Internet Protocol 

WFQ Weighted Fair Queuing 
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APPENDIX B Example Queuing Architectures for RG and BRAS 
Example Queuing Architecture for RG 

The queuing and scheduling discipline envisioned upstream for the RG is shown in Figure 24. 

monXcSm 1^S?^ ippcrW I** m ° del - however ' a " *** is scheduled in a 

taare aSi in faiSJ ^g^aPPear at first that the Diffserv queuing and scheduling might apply ortyto 
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Figure 22 - Queuing and Scheduling Example for RG 

In Figure 22 the following abbreviations apply: 
ASP - Application Service Provider 
PTA - PPP Terminated Aggregation 
PPP - Point-to-Point Protocol 

EF - Expedited Forwarding - as defined in RFC [This should be "RFC 32461 
AF - Assured Forwarding - as defined in RFC 2597 
BE - Best Effort forwarding 
RL - Rate Limiter 

£RL - Summing Rate Limiter (limits multiple flows) 
S- Scheduler 



Example Queuing Architecture for a BRAS that can also switch ATM 

An example of a queuing and scheduling discipline for a BRAS that meets the hierarchical shaping/scheduling 
requirements envisioned downstream is shown in Figure 24. Note that in this example, the BRAS is also an 
ATM switch, although the ATM switching capability is not essential for all BRAS designs. 

There are multiple access sessions supported in this model, however, all traffic is classified and scheduled in a 
monolithic system. So, while it might appear at first that the Diffserv queuing and scheduling might apply only to 
IP-aware access - in fact all access, IP, Ethernet, PPP, and even ATM is managed by the same system that 
adheres to a combination of queuing disciplines taken from ATM and the Diffserv model. Note that the ATM 
disciplines are for backward compatibility, and don't otherwise interact, with the Diffserv disciplines. 

The BRAS will need to provide a congestion management function that will allow the synthesis of IP QoS 
through downstream elements that are not QoS aware. Accomplishing this is envisioned as a marriage of IP 
and ATM technologies with ATM and WFQ scheduling performed against diffserv and ATM queues. At a very 
high level, the queuing architecture desired for the BRAS can be described as IP DiffServ classification and 
queues mated to a slightly enhanced ATM scheduler. This results in emitting (shaping) ATM cells into the 
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downstream network according to their VC contracts, ATM traffic engineering requirements, and so that no 
congestion occurs on the downstream links and systems. The result is that congestion queues in the BRAS, 
and eventual data discard occurs in packets being dropped from the DiffServ queues according to their 
precedence. 

Figure 23 is provided as a reference to reinforce the problem and to provide exemplary infrastructure to show 
how the queuing system works. 
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Figure 23 - Reference Topology for Queuing and Scheduling Example for a BRAS that can also switch ATM 



In this example the BRAS is on the left and uses a central ATM switch to multiplex access to 3 DSLAMs 5 at the 
top, right, and bottom. The DSLAM on the right has an additional RT unit daisy-chained behind it using a T1 
IMA group. Various RGs are behind the ADSL lines at differing sync rates. As stated in WT81, there is an 
assumption that congestion in this network never occurs in the fabric of the ATM switch, DSLAMs, or RT units, 
and always occurs through the over-subscription of transport links. In this example, those links would be: 

1 ) OC 3 between BRAS and ATM switch 

2) DS3 between ATM switch and DSLAMs 

3) T1 IMA between DSLAM and RT 

4) DSL loop to the RGs 

Now, we observe traffic entering the BRAS and its queuing discipline, and see the following: 

1 ) First, traffic is classified in a similar way to what was described for the RG. One notable exception being 
legacy ATM traffic, which is queued according to VC. 

2) It is then policed, or rate limited, according to the services associated with the queues (if any). Again 
with an ATM exception of applying ATM-appropriate disciplines, such as CBR, VBR or UBR. 

Traffic remains in the queues until it is scheduled for delivery. If congestion would occur in the BRAS or on a 
downstream link : then the queues for that traffic fill according to their discipline. 
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1 ) The scheduler is best described in reverse. First, the egress port of the BRAS is scheduled to the port 
rate (OC3 in this example). At this level, the scheduler is set for a WFQ algorithm, weighted according 
to the data rates of the VPs that are scheduled. Traffic is "pulled" from the subordinate schedulers in 
priority (as described for the RG scheduler) but with the limitations set by the various subordinate 

schedulers. _ , , . J 

2) Then each ATM VP is scheduled. In this case there are 3 DS3 VPs that each lead to a different 
DSLAM and are scheduled to the DS3 rate. The schedulers are set to work in a similar way to the 
egress port scheduler. . „ „ ._ 

3) In a departure from a typical ATM device, an additional layer of hierarchy is defined for groups of VCs 
in order to account for bandwidth constraints beyond the DSLAM. This can occur with DLC-based and 
RT-based DSLAMs that typically us IMA groups daisy-chained into Co-based DSLAMs. In this 
example, the VC Group Scheduler accounts for the T1 IMA group to the RT. 

4) The next stage is the scheduler for the ATM VC. This scheduler works almost exactly like the RG. In 
the (optional) case where 2 PVCs are used the bandwidth of the DSL line is divided between the 2 
PVCs instead of being directly assigned. 

5) Finally the queues within a given access session are scheduled to a maximum rate assigned to the 
access session. Initially static, the limit eventually becomes profile-driven through the policy server. 

As was described for the RG queuing architecture, all the outputs of the EF, AF, and BE queues are sent to a 
(hierarchical) scheduler (S) that pulls traffic from them in a strict priority fashion. In this configuration EF traffic 
is obviously, given highest precedence. However, BE is not given the lowest. Of the three levels of drop 
precedence that the AF system can emit, the middle level is equated with BE. This creates the opportunity to 
establish access types with a lower priority than existing BE PPP access. Note that this definition goes beyond 
the current Diffserv RFC specifications. 
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Figure 24 - Queuing and Scheduling Example for a BRAS that can also switch ATM 



In Figure 24 the following abbreviations apply: 
ASP - Application Service Provider 
ATM - Asynchronous Transfer Mode 
PTA - PPP Terminated Aggregation 
PPP - Point-to-Point Protocol 
S - Scheduler 
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APPENDIX C SAMPLE MESSAGE EXCHANGE FOR BASIC 
SESSION ESTABLISHMENT WITH RSVP 

This appendix includes an example message exchange establishing a dynamic QoS enabled service. This 
message exchange is not complete. Other logical elements or signaling protocols may be required. While 
certain protocols are explicitly shown, it should be used as a high level reference that will be updated in 
subsequent versions of the document. 

Policy 

Server/ ... 

Session Access Node 

Manager BRAS ATM ATU-R CPE 
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